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Abstract 


The Session Description Protocol (SDP) provides mechanisms to 
describe attributes of multimedia sessions and of individual media 
streams (e.g., Real-time Transport Protocol (RTP) sessions) within a 
multimedia session, but does not provide any mechanism to describe 
individual media sources within a media stream. This document 
defines a mechanism to describe RTP media sources, which are 
identified by their synchronization source (SSRC) identifiers, in 
SDP, to associate attributes with these sources, and to express 
relationships among sources. It also defines several source-level 
attributes that can be used to describe properties of media sources. 
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1. Introduction 


The Session Description Protocol (SDP) [RFC4566] provides mechanisms 
to describe attributes of multimedia sessions and of media streams 
(e.g., Real-time Transport Protocol (RTP) [RFC3550] sessions) within 
a multimedia session, but does not provide any mechanism to describe 
individual media sources within a media stream. 
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Several recently proposed protocols, notably RTP single-source 
multicast [EXT-SSM], have found it useful to describe specific media 
sources in SDP messages. Single-source multicast, in particular, 
needs to ensure that receivers’ RTP synchronization source (SSRC) 
identifiers do not collide with those of media senders, as the RTP 
specification [RFC3550] requires that colliding sources change their 
SSRC values after a collision has been detected. Earlier work has 
used mechanisms specific to each protocol to describe the individual 
sources of an RTP session. 


Moreover, whereas the Real-time Transport Protocol (RTP) [RFC3550] is 
defined as allowing multiple sources in an RTP session (for example, 
if a user has more than one camera), SDP has no existing mechanism 
for an endpoint to indicate that it will be using multiple sources or 
to describe their characteristics individually. 


To address all these problems, this document defines a mechanism to 
describe RTP sources, identified by their synchronization source 
(SSRC) identifier, in SDP, to associate attributes with these 
sources, and to express relationships among individual sources. It 
also defines a number of new SDP attributes that apply to individual 
sources ("Source-level" attributes), describes how a number of 
existing media stream ("media-level") attributes can also be applied 
at the source level, and establishes IANA registries for source-level 
attributes and source grouping semantics. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119] and 
indicate requirement levels for compliant implementations. 


3. Overview 


In the Real-time Transport Protocol (RTP) [RFC3550], an association 
among a group of communicating participants is known as an RTP 
Session. An RTP session is typically associated with a single 
transport address (in the case of multicast) or communication flow 
(in the case of unicast), though RTP translators and single-source 
multicast [EXT-SSM] can make the situation more complex. RTP 
topologies are discussed in more detail in [RFC5117]. 


Within an RTP session, the source of a single stream of RTP packets 
is known as a synchronization source (SSRC). Every synchronization 
source is identified by a 32-bit numeric identifier. In addition, 
receivers (who may never send RTP packets) also have source 
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identifiers, which are used to identify their RTP Control Protocol 
(RTCP) receiver reports and other feedback messages. 


Messages of the Session Description Protocol (SDP) [RFC4566], known 
as session descriptions, describe multimedia sessions. A multimedia 
session is a set of multimedia senders and receivers as well as the 
data streams flowing from senders to receivers. A multimedia session 
contains a number of media streams, which are the individual RTP 
sessions or other media paths over which one type of multimedia data 
is carried. Information that applies to an entire multimedia session 
is called session-level information, while information pertaining to 
one media stream is called media-level information. The collection 
of all the information describing a media stream is known as a media 
description. (Media descriptions are also sometimes known informally 
as SDP "m"-lines, after the SDP syntax that begins a media 
description.) Several standard information elements are defined at 
both the session level and the media level. Extended information can 
be included at both levels through the use of attributes. 


(The term "media stream" does not appear in the SDP specification 
itself, but is used by a number of SDP extensions, for instance, 
Interactive Connectivity Establishment (ICE) [ICE], to denote the 
object described by an SDP media description. This term is 
unfortunately rather confusing, as the RTP specification [RFC3550] 
uses the term "media stream" to refer to an individual media source 
or RTP packet stream, identified by an SSRC, whereas an SDP media 
stream describes an entire RTP session, which can contain any number 
of RTP sources. In this document, the term "media stream" means an 
SDP media stream, i.e., the thing described by an SDP media 
description, whereas "media source" is used for a single source of 
media packets, i.e., an RTP media stream.) 


The core SDP specification does not have any way of describing 
individual media sources, particularly RTP synchronization sources, 
within a media stream. To address this problem, in this document we 
introduce a third level of information, called source-level 
information. Syntactically, source-level information is described by 
a new SDP media-level attribute, "ssrc", which identifies specific 
synchronization sources within an RIP session and acts as a meta- 
attribute mapping source-level attribute information to these 
sources. 


This document also defines an SDP media-level attribute, "ssrc- 
group", which can represent relationships among media sources within 
an RTP session in much the same way as the "group" attribute 
[RFC3388] represents relationships among media streams within a 
multimedia session. 
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4. Media Attributes 


This section defines two media-level attributes, "ssrc" and "ssrc- 
group". 


4.1. The "ssrc" Media Attribute 


a=ssrc:<ssrc-id> <attribute> 
a=ssrc:<ssrc-id> <attribute>:<value> 


The SDP media attribute "ssrc" indicates a property (known as a 
"source-level attribute") of a media source (RTP stream) within an 
RTP session. <ssrc-id> is the synchronization source (SSRC) ID of the 
source being described, interpreted as a 32-bit unsigned integer in 
network byte order and represented in decimal. <attribute> or 
<attribute>:<value> represents the source-level attribute specific to 


the given media source. The source-level attribute follows the 
syntax of the SDP "a=" line. It thus consists of either a single 
attribute name (a flag) or an attribute name and value, e.g., 
"cname:user@example.com". No attributes of the former type are 


defined by this document. 


Within a media stream, "ssrce" attributes with the same value of 
<ssrc-id> describe different attributes of the same media sources. 
Across media streams, <ssrc-id> values are not correlated (unless 
correlation is indicated by media-stream grouping or some other 
mechanism) and MAY be repeated. 


Each "ssrc" media attribute specifies a single source-level attribute 
for the given <ssrc-id>. For each source mentioned in SDP, the 
source-level attribute "cname", defined in Section 6.1, MUST be 
provided. Any number of other source-level attributes for the source 
MAY also be provided. 


The "ssrc" media attribute MAY be used for any RTP-based media 
transport. It is not defined for other transports. 


If any other SDP attributes also mention RTP SSRC values (for 
example, Multimedia Internet KEYing (MIKEY) [RFC3830] [RFC4567]), the 
values used MUST be consistent. (These attributes MAY provide 
additional information about a source described by an "ssrc" 
attribute or MAY describe additional sources.) 


Though the source-level attributes specified by the ssrc property 
follow the same syntax as session-level and media-level attributes, 
they are defined independently. All source-level attributes MUST be 
registered with IANA, using the registry defined in Section 12.2. 
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Figure 4 in Section 10 gives a formal Augmented Backus-Naur Form 
(ABNF) [RFC5234] grammar for the "ssrc" attribute. 


The "ssrc" media attribute is not dependent on charset. 
4.2. The "ssrc-group" Media Attribute 
a=ssrc-group:<semantics> <ssrc-id> 


The SDP media attribute "ssrc-group" expresses a relationship among 
several sources of an RTP session. It is analogous to the "group" 
session-level attribute [RFC3388], which expresses a relationship 
among media streams in an SDP multimedia session (i.e., a 
relationship among several logically related RIP sessions). As 
sources are already identified by their SSRC IDs, no analogous 
property to the "mid" attribute is necessary; groups of sources are 
identified by their SSRC IDs directly. 


The <semantics> parameter is taken from the specification of the 


"group" attribute [RFC3388]. The initial semantic values defined for 
the "ssrc-group" attribute are FID (Flow Identification) [RFC3388] 
and FEC (Forward Error Correction) [RFC4756]. In each case, the 


relationship among the grouped sources is the same as the 
relationship among corresponding sources in media streams grouped 
using the SDP "group" attribute. 


Though the "ssrc-group" semantic values follow the same syntax as 
"group" semantic values, they are defined independently. All "ssrc- 
group" semantic values MUST be registered with IANA, using the 
registry defined in Section 12.3. 


(The other "group" semantics registered with IANA as of this writing 
are not useful for source grouping. LS (Lip Synchronization) 
[RFC3388] is redundant for sources within a media stream as RTP 
sources with the same CNAME are implicitly synchronized in RTP. SRF 
(Single Reservation Flow) [RFC3524] and ANAT (Alternative Network 
Address Types) [RFC4091] refer specifically to the media stream’s 
transport characteristics. CS (Composite Session) [FLUTE] is used to 
group FLUTE sessions, and so is not applicable to RTP.) 


The "ssrc-group" attribute indicates the sources in a group by 
listing the <ssrc-id>s of the sources in the group. It MUST list at 
least one <ssrc-id> for a group and MAY list any number of additional 


ones. Every <ssrc-id> listed in an "ssrc-group" attribute MUST be 
defined by a corresponding "ssrc:" line in the same media 
description. 


The "ssrc-group" media attribute is not dependent on charset. 
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I; 


Figure 5 in Section 10 gives a formal Augmented Backus-Naur Form 
(ABNF) [RFC5234] grammar for the "ssrc-group" attribute. 


Usage of Identified Source Identifiers in RTP 


The synchronization source identifiers used in an RTP session are 
chosen randomly and independently by endpoints. As such, it is 
possible for two RTP endpoints to choose the same SSRC identifier. 
Though the probability of this is low, the RTP specification 
[RFC3550] requires that all RTP endpoints MUST be prepared to detect 
and resolve collisions. 


As a result, all endpoints MUST be prepared for the fact that 
information about specific sources identified in a media stream might 
be out of date. The actual binding between SSRCs and source CNAMEs 
can only be identified by the source description (SDES) RTCP packets 
transmitted on the RTP session. 


When endpoints are choosing their own local SSRC values for media 
streams for which source-level attributes have been specified, they 
MUST NOT use for themselves any SSRC identifiers mentioned in media 
descriptions they have received for the media stream. 


However, sources identified by SDP source-level attributes do not 
otherwise affect RTP transport logic. Specifically, sources that are 
only known through SDP, for which neither RTP nor RTCP packets have 
been received, MUST NOT be counted for RTP group size estimation, and 
report blocks MUST NOT be sent for them in SR or RR RTCP messages. 


Endpoints MUST NOT assume that only the sources mentioned in SDP will 
be present in an RTP session; additional sources, with previously 
unmentioned SSRC IDs, can be added at any time, and endpoints MUST be 
prepared to receive packets from these sources. (How endpoints 
handle such packets is not specified here; they SHOULD be handled in 
the same manner as packets from additional sources would be handled 
had the endpoint not received any a=ssrc: attributes at all.) 


An endpoint that observes an SSRC collision between its explicitly 
signaled source and another entity that has not explicitly signaled 
an SSRC MAY delay its RTP collision-resolution actions [RFC3550] by 
5*1.5*Td, where Td is the deterministic, calculated, reporting 
interval for receivers defined in Section 6.3.1 of the RTP 
specification [RFC3550], to see whether the conflict still exists. 
(This gives precedence to explicitly signaled sources and places the 
burden of collision resolution on non-signaled sources.) SSRC 
collisions between multiple explicitly-signaled sources, however, 
MUST be acted upon immediately. 
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If, following RTP’s collision-resolution procedures [RFC3550], a 
source identified by source-level attributes has been forced to 
change its SSRC identifier, the author of the SDP containing the 
source-level attributes for these sources SHOULD send out an updated 
SDP session description with the new SSRC if the mechanism by which 
SDP is being distributed for the multimedia session has a mechanism 
to distribute updated SDP. This updated SDP MUST include a 
"previous-—ssrc" source-level attribute, described in Section 6.2, 
listing the source’s previous SSRC ID. (If only a single source with 
a given CNAME has collided, the other RTP session members can infer a 
correspondence between the source’s old and new SSRC IDs without 


requiring an updated session description. However, if more than one 
source collides at once, or if sources are leaving and re-Jjoining, 
this inference is not possible. To avoid confusion, therefore, 


sending updated SDP messages is always RECOMMENDED.) 


Endpoints MUST NOT reuse the same SSRC ID for identified sources with 
the same CNAME for at least the duration of the RTP session's 
participant timeout interval (see Section 6.3.5 of [RFC3550]). They 
SHOULD NOT reuse any SSRC ID ever mentioned in SDP (either by 
themselves or by other endpoints) for the entire lifetime of the RTP 
session. 


Endpoints MUST be prepared for the possibility that other parties in 
the session do not understand SDP source-level attributes, unless 
some higher-level mechanism normatively requires them. See Section 9 
for more discussion of this. 


6. Source Attributes 


This section describes specific source attributes that can be applied 
to RTP sources. 


6.1. The "cname" Source Attribute 
a=ssrc:<ssrc-id> cname:<cname> 


The "cname" source attribute associates a media source with its 
Canonical End-Point Identifier (CNAME) source description (SDES) 
item. This MUST be the CNAME value that the media sender will place 
in its RTCP SDES packets; it therefore MUST follow the syntax 
conventions of CNAME defined in the RTP specification [RFC3550]. If 
a session participant receives an RTCP SDES packet associating this 
SSRC with a different CNAME, it SHOULD assume there has been an SSRC 
collision and that the description of the source that was carried in 
the SDP description is not applicable to the actual source being 
received. This source attribute is REQUIRED to be present if any 
source attributes are present for a source. The "cname" attribute 
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MUST NOT occur more than once for the same ssrc-id within a given 
media stream. 


The "cname" source attribute is not dependent on charset. 


Figure 6 in Section 10 gives a formal Augmented Backus-Naur Form 
(ABNF) [RFC5234] grammar for the "cname" attribute. 


6.2. The "previous-ssrc" Source Attribute 
a=ssrc:<ssrc-id> previous-ssrc:<ssrc-id> 


The "previous-ssrc" source attribute associates a media source with 
previous source identifiers used for the same media source. 
Following an SSRC change due to an SSRC collision involving a media 
source described in SDP, the updated session description describing 
the source’s new SSRC (described in Section 5) MUST include the 
"previous-ssrc" attribute associating the new SSRC with the old one. 
If further updated SDP descriptions are published describing the 
media source, the "previous-ssrc" attribute SHOULD be included if the 
session description was generated before the participant timeout of 
the old SSRC, and MAY be included after that point. This attribute, 
if present, MUST list at least one previous SSRC and MAY list any 
number of additional SSRCs for the source if the source has collided 
more than once. This attribute MUST be present only once for each 
source. 


The "previous-ssrc" source attribute is not dependent on charset. 


Figure 7 in Section 10 gives a formal Augmented Backus-Naur Form 
(ABNF) [RFC5234] grammar for the previous-ssrc attribute. 


6.3. The "fmtp" Source Attribute 
a=ssrc:<ssrc> fmtp:<format> <format specific parameters> 


The "fmtp" source attribute allows format-specific parameters to be 
conveyed about a given source. The <format> parameter MUST be one of 
the media formats (i.e., RTP payload types) specified for the media 
stream. The meaning of the <format specific parameters> is unique 
for each media type. This parameter MUST only be used for media 
types for which source-level format parameters have explicitly been 
specified; media-level format parameters MUST NOT be carried over 
blindly. 


The "fmtp" source attribute is not dependent on charset. 
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6.4. Other Source Attributes 


This document only defines source attributes that are necessary or 
useful for an endpoint to decode and render the sources in a media 
stream. It does not include any attributes that would contribute to 
an endpoint’s decision to accept or reject a stream, e.g., in an 
offer/answer exchange. Such attributes are for future consideration. 


7. Examples 


This section gives several examples of SDP descriptions of media 
sessions containing source attributes. For brevity, only the media 
sections of the descriptions are given. 


m=audio 49168 RTP/AVP 0 
a=ssrc:314159 cname:user@example.com 


Figure 1: Example of a declaration of a single synchronization source 


The example in Figure 1 shows an audio stream advertising a single 
source. 


m=video 49170 RTP/AVP 96 

a=rtpmap:96 H264/90000 

a=ssrc:12345 cname:another-user@example.com 
a=ssrc:67890 cname:another-user@example.com 


Figure 2: Example of a media stream containing several independent 
sources from a single session member 


The example in Figure 2 shows a video stream where one participant 


(identified by a single CNAME) has several cameras. The sources 
could be further distinguished by RTCP Source Description (SDES) 
information. 


m=video 49174 RTP/AVPF 96 98 
a=rtpmap:96 H.264/90000 

a=rtpmap:98 rtx/90000 

a=fmtp:98 apt=96; rtx-time=3000 
a=ssrc-group:FID 11111 22222 
a=ssrc:11111 cname:user3@example.com 
a=ssre:22222 cname:user3@example.com 
a=ssrc-group:FID 33333 44444 
a=ssrc:33333 cname:user3@example.com 
a=ssrc:44444 cname:user3@example.com 


Figure 3: Example of the relationships among 
several retransmission sources 
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The example in Figure 3 shows how the relationships among sources 
used for RTP retransmission [RFC4588] can be explicitly signaled. 
This prevents the complexity of associating original sources with 
retransmission sources when SSRC multiplexing is used for RIP 
retransmission, as is described in Section 5.3 of [RFC4588]. 


8. Usage With the Offer/Answer Model 


When used with the SDP Offer/Answer Model [RFC3264], SDP source- 
specific attributes describe only the sources that each party is 
willing to send (whether it is sending RTP data or RTCP report 
blocks). No mechanism is provided by which an answer can accept or 
reject individual sources within a media stream; if the set of 
sources in a media stream is unacceptable, the answerer’s only option 
is to reject the media stream or the entire multimedia session. 


The SSRC IDs for sources described by an SDP answer MUST be distinct 
from the SSRC IDs for sources of that media stream in the offer. 
Similarly, new SSRC IDs in an updated offer MUST be distinct from the 
SSRC IDs for that media stream established in the most recent offer/ 
answer exchange for the session and SHOULD be distinct from any SSRC 
ID ever used by either party within the multimedia session (whether 
or not it is still being used). 


9. Backward Compatibility 


According to the definition of SDP, interpreters of SDP session 
descriptions ignore unknown attributes. Thus, endpoints MUST be 
prepared that recipients of their RTP media session may not 
understand their explicit source descriptions, unless some external 
mechanism indicates that they were understood. In some cases (such 
as RTP Retransmission [RFC4588]), this may constrain some choices 
about the bitstreams that are transmitted. 


Source descriptions are specified in this document such that RTP 
endpoints that are compliant with the RTP specification [RFC3550] 
will be able to decode the media streams they describe whether or not 
they support explicit source descriptions. However, some deployed 
RTP implementations may not actually support multiple media sources 
in a media stream. Media senders MAY wish to restrict themselves to 
a single source at a time unless they have some means of concluding 
that the receivers of the media stream support source multiplexing. 
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10. Formal Grammar 


This section gives a formal Augmented Backus-Naur Form (ABNF) 
[RFC5234] grammar for each of the new media and source attributes 


defined in this document. Grammars for existing session or media 
attributes that have been extended to be source attributes are not 
included. 


Copyright (c) 2009 IETF Trust and the persons identified as authors 
of the code. All rights reserved. 


Redistribution and use in source and binary forms, with or without 
modification, are permitted provided that the following conditions 
are met: 


o Redistributions of source code must retain the above copyright 
notice, this list of conditions and the following disclaimer. 


o Redistributions in binary form must reproduce the above copyright 
notice, this list of conditions and the following disclaimer in 
the documentation and/or other materials provided with the 
distribution. 


o Neither the name of Internet Society, IETF or IETF Trust, nor the 
names of specific contributors, may be used to endorse or promote 
products derived from this software without specific prior written 
permission. 


THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 
‘AS IS’ AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 


Lennox, et al. Standards Track [Page 12] 


RFC 5576 Source-Specific SDP Attributes June 2009 


11. 


ssrc-attr = "ssrce:" ssrc-id SP attribute 

; The base definition of "attribute" is in RFC 4566. 
; (It is the content of "a=" lines.) 

ssrc-id = integer ; 0 .. 2**32 - 1 


attribute =/ ssrc-attr 


Figure 4: Syntax of the "ssrc" media attribute 


ssrc-group-attr = "ssrc-group:" semantics *(SP ssrc-id) 


"FEC" / "FID" / token 
; Matches RFC 3388 definition and 
; IANA registration rules in this doc. 


semantics 


token = <as defined in RFC 4566> 
attribute =/ ssrc-group-attr 


Figure 5: Syntax of the "ssrc-group" media attribute 


cname-attr = "cname:" cname 


cname = byte-string 
; Following the syntax conventions for CNAME as defined in RFC 3550. 
; The definition of "byte-string" is in RFC 4566. 


attribute =/ cname-attr 


Figure 6: Syntax of the "cname" source attribute 


previous-ssrc-attr = "previous-ssrc:" ssrc-id * (SP ssrc-id) 
attribute =/ previous-ssrc-attr 
Figure 7: Syntax of the "previous-ssrc" source attribute 
Security Considerations 
All the security implications of RTP [RFC3550] and of SDP [RFC4566] 


apply. Explicitly describing the multiplexed sources of an RTP media 
stream does not appear to add any further security issues. 
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T2 


T2: 


12 


IANA Considerations 
1. New SDP Media-Level Attributes 


This document defines two SDP media-level attributes: "ssrc" and 
"ssrc-group". These attributes have been registered by IANA under 
"Session Description Protocol (SDP) Parameters" under "att-—field 
(media level only)". 


The "ssrce" attribute is used to identify characteristics of media 
sources within a media stream. Its format is defined in Section 4.1. 


The "ssrc-group" attribute is used to identify relationships among 
media sources within a media stream. Its format is defined in 
Section 4.2. 


-2. Registry for Source-Level Attributes 


This specification creates a new IANA registry named "att-field 
(source level)" within the SDP parameters registry. Source 
attributes MUST be registered with IANA and documented under the same 
rules as for SDP session-level and media-level attributes as 
specified in [RFC4566]. 


New attribute registrations are accepted according to the 
"Specification Required" policy of [RFC5226], provided that the 
specification includes the following information: 

o contact name, email address, and telephone number 

o attribute name (as it will appear in SDP) 

o long-form attribute name in English 

o whether the attribute value is subject to the charset attribute 

Oo a one-paragraph explanation of the purpose of the attribute 

oO a specification of appropriate attribute values for this attribute 
The above is the minimum that IANA will accept. The Expert Reviewer 
will determine if the proposed attributes are expected to see 


widespread use and interoperability; in that case, the attributes 
MUST be specified in a Standards Track RFC. 
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Submitters of registrations should ensure that the specification is 
in the spirit of SDP attributes, most notably that the attribute is 
platform independent in the sense that it makes no implicit 
assumptions about operating systems and does not name specific pieces 
of software in a manner that might inhibit interoperability. 


Source-level attributes that are substantially similar in semantics 
to existing session-level or media-level attributes SHOULD reuse the 
same attribute name as those session-level or media-level attributes. 
Source-level attributes SHOULD NOT reuse attribute names of session- 
level or media-level attributes that are unrelated or substantially 
different. 


The initial set of source attribute names, with definitions in 
Section 6 of this document, is in Figure 8. 


Type SDP Name Reference 


att-field (source level) 


cname [RFC5576] 
previous-ssrc [RFC5576] 
fmtp [RFC5576] 


Figure 8: Initial contents of the IANA Source Attribute Registry 
3. Registry for Source Grouping Semantics 


This specification creates a new IANA registry named ’Semantics for 
the "ssrc-group" SDP Attribute’ within the SDP parameters registry. 
Source group semantics MUST be defined in Standards Track RFCs, under 
the same rules as [RFC3388]. 


The IANA Considerations section of the RFC MUST include the following 
information, which appears in the IANA registry along with the RFC 
number of the publication: 


o A brief description of the semantics. 


o Token to be used within the group attribute. This token may be of 
any length, but SHOULD be no more than four characters long. 


o Reference to a Standards Track RFC. 


Source grouping semantic values that are substantially similar to 
existing media grouping semantic values SHOULD reuse the same 
semantics name as those media grouping semantics. Source grouping 
semantics SHOULD NOT reuse source grouping semantic names that are 
unrelated or substantially different. 
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The initial set of source grouping semantic values, for the semantics 
specified in Section 4.2 of this document, is in Figure 9. 


Semantics Token Reference 
Flow Identification FID [RFC5576] 
Forward Error Correction FEC [RFC5576] 


Figure 9: Initial Contents of IANA Source Group Semantics Registry 
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